Patient records are not just lines of codes in a database, they are
private stories, containing very very sensitive information. Yet
many hospitals in Nigeria and across West Africa still use systems
that leave those records exposed: Most EMR installations run over
plain http, store passwords in cleartext and keep
backup without encryption. This post explains why encryption and
data masking matter, how they protect patients, and what hospital
leaders and EMR solution providers must do today to bring systems up
to global standards.
Why encryption and masking are essential for healthcare
Encryption turns readable data into ciphertext that is meaningless without the correct decryption key. Masking (or pseudonymization) removes or replaces identifying fields so data can be used for testing or analytics without exposing actual patient identities. Together they reduce the chance that stolen information will cause harm. International frameworks; HIPAA, GDPR and ISO standards, all expect health organizations to apply strong cryptography and data minimization. In practice, properly encrypted data can mean the difference between a contained incident and a full-scale breach that destroys patient trust and triggers heavy regulatory scrutiny.
The Nigerian reality: dangerous assumptions and common failures
In Nigeria many hospitals subscribe to EMR-as-a-Service platforms
which are mostly locally hosted EMR packages. Because these systems
often run on internal networks, a common (but dangerous) assumption
is that internal traffic does not need TLS/HTTPS. As a result, most
EMR web consoles and APIs are accessible via
http:// with credentials and PHI transmitted in plain
text across the local LAN. If any device on that network is
compromised, an attacker can sniff traffic and capture usernames,
passwords and patient records.
Even worse, there are documented cases in the wider healthcare market where vendors stored user passwords in cleartext or with weak reversible encryption at the backend, meaning a database leak instantly exposes every account. Combine that with weak staff password habits (e.g., “1234”, “password”) and unlocked workstations, and you have a recipe for a disastrous compromise. These practices not only violate the spirit of global standards but actively undermine patient safety and institutional credibility.
Encryption in transit:
All web access to EMRs, portals and APIs must use TLS (HTTPS). This should be true even on local networks. TLS prevents passive network eavesdroppers from reading credentials or patient data. EMR solutions should:
- Require HTTPS for web service access, both hosted locally and external. As a requirement for this, service providers must install valid TLS certificates (not self-signed certificates where applicable).
- Enforce secure email gateways (TLS/S/MIME) or secure patient portals for transmitting PHI rather than relying on plain SMTP or personal email accounts.
- Use encrypted VPNs or encrypted tunnels for remote administrative access and for any vendor access to on-prem systems.
Even seemingly private LAN traffic can be intercepted if an attacker has a foothold on the network. HTTPS by default removes that risk and is a low-cost, high-impact control.
Encryption at rest:
Data at rest includes databases, file shares, desktops, laptops, mobile devices and backup media. Hospitals should make encryption of stored PHI a default:
- Use database-level encryption (Transparent Data Encryption or column-level encryption) for EMR backends so that exported copies remain protected.
- Enable full-disk encryption on servers, workstations and laptops to protect against data loss in the event of device theft.
- Ensure backups; cloud snapshots or physical drives, are encrypted with strong encryption keys and stored separately from the production environment.
- Keep encryption keys in secure key management systems (HSMs or cloud key vaults) and rotate keys on a regular schedule.
If a storage device or backup is stolen, encryption at rest ensures attackers cannot read stored data.
Password storage and authentication:
It is unacceptable for any EMR vendor to store passwords in cleartext. Best practice is to store only salted, password hashes (e.g., bcrypt, Argon2). Hospitals and other health facilities that use these services must require vendors to demonstrate how they handle credentials:
- Ask vendors how they store passwords.
- Require multi-factor authentication (MFA) for all remote administrative and clinician access to EMR systems.
- Enforce password policies: length, complexity, and rotation, and centrally manage authentication where possible (e.g. LDAP, SSO with strong controls etc).
A leaked database with cleartext passwords means immediate account takeover, and exposed patient's sensitive data across the hospital, and if staff reuse these passwords elsewhere, the damage becomes exponential.
Data masking and pseudonymization:
Masking replaces or obfuscates identifiers (names, IDs, contact info) so datasets can be used for testing, analytics, research or other purposes without exposing real patient identities. Practical masking practices include:
Vendor responsibility:
Because many hospitals run third-party EMR services, security must be contractually required. Hospital leaders should insist that vendors:
- Use HTTPS for all deployments, even local ones, and provide documented certificate management practices.
- Encrypt data at rest and in backups and provide proof of key management and rotation policies.
- Store credentials using modern salted hashing algorithms and support MFA and role-based access control.
- Provide audit logs showing who accessed or changed records and allow customers to review these logs.
- Support data masking for non-production environments and demonstrate secure development lifecycle practices (regular security testing and penetration testing).
Practical steps hospitals can take now
- Enable HTTPS across all internal and external services. Use trustworthy certificates and automate renewal where possible.
- Encrypt backups and test restores regularly so you know your encrypted backups actually work.
- Require vendors to provide proof of password hashing methods, encryption standards and key management. Refuse solutions that store credentials in plaintext.
- Mask data before using it in staging, analytics or for research and troubleshooting. Never hand production PHI to a vendor without a masking step or a strict NDA and equivalent safeguards.
- Train staff on why encryption matters and on safe data-handling: no saving passwords in plain files, no sharing accounts, and locking screens when away from workstations.
These steps are not “nice-to-have” but are are foundational for patient safety in this new age. Many attacks succeed because of trivial gaps; an unencrypted API endpoint, an unencrypted backup drive, etc. making little changes to our current systems can have a huge impact on the overall security of these systems.
Conclusion: move from assumptions to demonstrable security
In Nigeria and West Africa, the path forward is clear: hospitals must stop assuming internal networks are safe, demand secure-by-default practices from EMR providers, and implement encryption and masking across all environments. Regular audits, contractual security requirements for vendors, and a culture of data minimization and daily discipline will close the most common gaps.
